Event subscription and notification in network environments is becoming increasingly commonplace and important. Event subscription generally allows a first network entity to subscribe to event notifications from a second entity that may be related to a third network entity. Common examples of events include “presence” and “location;” however, the number and types of events are endless. For instance, conventional instant messaging services permit a first user to subscribe to a presence event for a second user. As such, during the period of the subscription, the first user receives updates as to the presence status (e.g., online or offline) of the second user. The subscription may be for a single inquiry, which will return a response of “present” or “not present” for the second user. The subscription may also be for a set period of time, which may result in multiple updates, or for other options (e.g., status change notifications, ongoing notifications, etc.)
Various protocols may be used for event subscription and notification. For example, the Session Initiation Protocol (SIP) may be used for such purposes. Although SIP is primarily a tool for initiating a communication session between endpoints, extensions to SIP have been proposed to provide event registration and trigger notification (see e.g., IETF document RFC 3265, “SIP-Specific Event Notification,” July 2002). Such a proposal, however, neither specifies the semantics of specific events, nor systems and methods for uploading event information.
Access control in general has been a topic for research, standardization, and product development for several years. It marks a fundamental task for information processing in which the rights of involved parties are controlled for access to, and the use of, certain resources and information, such as files and events. With regard to event subscription and notification, access control is typically governed by the particular event package. For example, instant messaging services generally maintain common host or central administration schemes that use proprietary software and methods for implementing their particular service. As such, access control to an event (e.g., permission for subscribing to notifications for the presence of a second user listed on a first user's buddy list) may be unique for the particular service. Such proprietary solutions may be acceptable for subscription to only a few events; however, as the number of event types increase and become more complex, these may become problematic.
As an example of the problems with proprietary methods for providing access control and/or access alerts (e.g., alerts for changes in access, alerts for access requests, etc.), consider a scenario involving a cascaded set of event servers. Suppose that a first event server provides events related to sensor information, such as GPS coordinates, and that a second event server subscribes to this information from the first one. For instance, the second server may use GPS coordinates of certain users to derive other information, such as location information that is more coarsely grained (e.g., city information for the certain users). Suppose that the city location information is then used as input through another event subscription to other event servers. Handling of access control in this cascaded case through proprietary methods for each server (or for each event package) may be extremely inefficient and very complex to handle—particularly for a user who is concerned about the usage of this type of information (i.e., his location).
Providing a standardized interface for specifying and handling access rights for the same information (e.g., location information) to any node (e.g., servers, mobile devices, PC's) may be very advantageous. Further, integrating access control functionality into a generic solution may greatly reduce the complexity for involved entities, particularly when an entity subscribes to a variety of different events. A candidate protocol for such a generic solution may include the Session Initiation Protocol (SIP); however, other protocols may also be used.
In the context of SIP and access rights, watcher subscriptions are known in which an entity is able to subscribe to the watcher list of a particular event, and as such, will be notified when a new user wishes to subscribe to a particular event. With the use of watcher subscriptions, on-line authorizations of subscriptions are supported. For example, suppose an online music video service allows users to request access to the service from a host entity. If a first user requests access from the host entity, and if an authorization entity for the music video service has subscribed to a “watcher” event related to access to the music video service, the authorization entity will receive a notification (“watcherinfo”) from the host entity. Otherwise stated, the authorization entity has subscribed to watcher information from the music video host entity.
The watcherinfo notification indicates that the first user desires access to the music video service and may include pertinent information, such as a URL for the first user. In order to change access rights for the first user (e.g., permit the first user to access the music video service), the authorization entity typically uses proprietary methods. In other words, watcher events themselves do not provide notifications of changes to access rights nor do they change access rights. They simply watch for access rights requests. As discussed previously, proprietary methods for changing access rights and/or providing notifications of such changes may be very inefficient and complex.
Thus, a need exists for systems and methods that provide access controlled event subscription using a common framework. Further, a need exists for systems and methods that provide access right change alerts using a common framework. Additionally, a need exists for systems and methods that provide access control for events through the use of access right change alerts using a common framework.